The DBMS must be capable of automatically disabling accounts after a 35-day period of account inactivity.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-52355	O112-C2-002100	SV-66571r1_rule		Medium

Description
Users are often the first line of defense within an application. Active users take notice of system and data conditions and are usually the first to notify systems administrators when they notice a system or application-related anomaly pertaining to their own account. Inactive user accounts pose a risk to systems and applications. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. Attackers that are able to exploit an inactive account can potentially obtain and maintain undetected access to an application. Applications need to track user inactivity and disable application accounts after an organization-defined period of inactivity. Such a process greatly reduces the risk that accounts will be misused, hijacked, or data compromised. Note that user authentication and account management should be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP This requirement applies to cases where it is necessary to have accounts directly managed by Oracle. Database accounts must be disabled by the DBMS, the OS, or an enterprise-level authentication/access mechanism after 35 days of inactivity in order to mitigate the risk of unauthorized access. Unauthorized access is particularly difficult to detect on unused accounts due to the lack of user oversight.

Description

Users are often the first line of defense within an application. Active users take notice of system and data conditions and are usually the first to notify systems administrators when they notice a system or application-related anomaly pertaining to their own account. Inactive user accounts pose a risk to systems and applications. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. Attackers that are able to exploit an inactive account can potentially obtain and maintain undetected access to an application. Applications need to track user inactivity and disable application accounts after an organization-defined period of inactivity. Such a process greatly reduces the risk that accounts will be misused, hijacked, or data compromised. Note that user authentication and account management should be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP This requirement applies to cases where it is necessary to have accounts directly managed by Oracle. Database accounts must be disabled by the DBMS, the OS, or an enterprise-level authentication/access mechanism after 35 days of inactivity in order to mitigate the risk of unauthorized access. Unauthorized access is particularly difficult to detect on unused accounts due to the lack of user oversight.

STIG	Date
Oracle Database 11.2g Security Technical Implementation Guide	2015-06-23

Details

Check Text ( C-54395r1_chk )
If all user accounts are managed and authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, stop here: this is not a finding against the DBMS. For accounts managed by Oracle, check DBMS settings to determine if accounts can be automatically disabled by the system after 35 days of inactivity. Also, ask the DBA if an alternative method, such as a stored procedure run daily, to disable Oracle-managed accounts inactive for more than 35 days, has been deployed. If the ability to disable accounts after 35 days of inactivity, by either of these means, does not exist, this is a finding. - - - - - Check to see what profile a user is associated with, if any, with this query: SQL> select username, profile from dba_users where username = '&Enter_Username'; Then check the profile to see what the password_life_time is set to in the table dba_profiles; The password_life_time is a value stored in the column named resource_name. SQL>select profile, resource_name, resource_type, limit from dba_profiles where upper(resource_name) = 'PASSWORD_LIFE_TIME'; - - - - - The following are notes on a method suggested by Oracle. In SRG-APP-000075-DB-000029 - The DBMS must, upon successful login, display to the user the date and time of the user's last login advocated using a custom trigger for this event. One could query the audit table and get similar results, but that is a much busier table with a lot more data. In SRG-APP-000075-DB-000029, we advocated to use a new table called sys.login_audit_info_all and trap login information with a login trigger. Check for the existence of the sys.login_audit_info_all and count the number of rows to ensure that the table is being used. Obviously, the table will have maintenance performed on it to shrink the contents, so the number of rows may vary. If the table itself exists, it is a good indication it is being used. Connect to the database, check for the existence of the table, and count the rows, as this will help us understand if the fix for SRG-APP-000075-DB-000029 was implemented and will help us remediate this issue. $ sqlplus connect as sysdba SQL> select count(*) from SYS.LOGIN_AUDIT_INFO_ALL; If the count is greater than zero, then the table exists and data is being inserted.

Check Text ( C-54395r1_chk )

If all user accounts are managed and authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, stop here: this is not a finding against the DBMS.

For accounts managed by Oracle, check DBMS settings to determine if accounts can be automatically disabled by the system after 35 days of inactivity. Also, ask the DBA if an alternative method, such as a stored procedure run daily, to disable Oracle-managed accounts inactive for more than 35 days, has been deployed.

If the ability to disable accounts after 35 days of inactivity, by either of these means, does not exist, this is a finding.

- - - - -

Check to see what profile a user is associated with, if any, with this query:
SQL> select username, profile
from dba_users
where username = '&Enter_Username';

Then check the profile to see what the password_life_time is set to in the table dba_profiles; The password_life_time is a value stored in the column named resource_name.

SQL>select profile, resource_name, resource_type, limit from dba_profiles where upper(resource_name) = 'PASSWORD_LIFE_TIME';

- - - - -

The following are notes on a method suggested by Oracle.

In SRG-APP-000075-DB-000029 - The DBMS must, upon successful login, display to the user the date and time of the user's last login advocated using a custom trigger for this event. One could query the audit table and get similar results, but that is a much busier table with a lot more data. In SRG-APP-000075-DB-000029, we advocated to use a new table called sys.login_audit_info_all and trap login information with a login trigger.

Check for the existence of the sys.login_audit_info_all and count the number of rows to ensure that the table is being used. Obviously, the table will have maintenance performed on it to shrink the contents, so the number of rows may vary. If the table itself exists, it is a good indication it is being used. Connect to the database, check for the existence of the table, and count the rows, as this will help us understand if the fix for SRG-APP-000075-DB-000029 was implemented and will help us remediate this issue.

$ sqlplus connect as sysdba
SQL> select count(*) from SYS.LOGIN_AUDIT_INFO_ALL;

If the count is greater than zero, then the table exists and data is being inserted.

Fix Text (F-57173r1_fix)
If all user accounts are managed and authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, no fix to the DBMS is required. For accounts managed by Oracle, determine if it is practical and acceptable to require a password change every 35 days or fewer, rather than the standard 60 days (as specified in SRG-APP-000174-DB-000080). If it is, issue the statement: ALTER PROFILE PPPPPP LIMIT PASSWORD_LIFE_TIME 35; (See the Oracle-provided $ORACLE_HOME/rdbms/admin/secconf.sql script for examples.) If password changes every 35 days or fewer are unacceptable or impractical, implement an alternative method, such as a stored procedure run daily, to disable accounts inactive for more than 35 days. - - - - - The following are notes on a method suggested by Oracle. Check either the login_audit_info_all or the dba_audit_session to see what users have not logged in for the site-defined number of days. If the login_audit_info_all exists, execute the following query to get a report of the users who have exceeded the site-specific guidelines and lock those accounts. Generate a report to see what users have not logged in in the last 30 days or whatever the site-specified expiration days requirement is. sqlplus connect as sysdba - If sys.login_audit_info_all exists and contains rows, use the following query to see if there are any users who have not logged in for a period of time that is defined as the amount of time required to generate a locked account. SQL>set linesize 121 SQL>col user_id format a30 SQL>col logoff_day format a20 Sal>select user_id, logoff_day from sys.login_audit_info_all where sysdate - logoff_day > &site_specified_expiration_days; sqlplus connect as sysdba - If sys.login_audit_info_all does not exist or contains no rows, use the following query to see if there are any users who have not logged in for a period of time that is defined as the amount of time required to generate a locked account. SQL>set linesize 121 SQL>col username format a30 SQL>col timestamp format a20 SQL> select username, timestamp from dba_audit_session where action_name = 'login' and sysdate - timestamp > &site_specified_expiration_days; Take the user returned from this report and expire the account. SQL> alter user &username account lock;

Fix Text (F-57173r1_fix)

If all user accounts are managed and authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, no fix to the DBMS is required.

For accounts managed by Oracle, determine if it is practical and acceptable to require a password change every 35 days or fewer, rather than the standard 60 days (as specified in SRG-APP-000174-DB-000080). If it is, issue the statement:
ALTER PROFILE PPPPPP LIMIT PASSWORD_LIFE_TIME 35;
(See the Oracle-provided $ORACLE_HOME/rdbms/admin/secconf.sql script for examples.)

If password changes every 35 days or fewer are unacceptable or impractical, implement an alternative method, such as a stored procedure run daily, to disable accounts inactive for more than 35 days.

- - - - -

The following are notes on a method suggested by Oracle.

Check either the login_audit_info_all or the dba_audit_session to see what users have not logged in for the site-defined number of days.

If the login_audit_info_all exists, execute the following query to get a report of the users who have exceeded the site-specific guidelines and lock those accounts.

Generate a report to see what users have not logged in in the last 30 days or whatever the site-specified expiration days requirement is.

sqlplus connect as sysdba - If sys.login_audit_info_all exists and contains rows, use the following query to see if there are any users who have not logged in for a period of time that is defined as the amount of time required to generate a locked account.

SQL>set linesize 121
SQL>col user_id format a30
SQL>col logoff_day format a20
Sal>select user_id,
logoff_day
from sys.login_audit_info_all
where sysdate - logoff_day > &site_specified_expiration_days;

sqlplus connect as sysdba - If sys.login_audit_info_all does not exist or contains no rows, use the following query to see if there are any users who have not logged in for a period of time that is defined as the amount of time required to generate a locked account.

SQL>set linesize 121
SQL>col username format a30
SQL>col timestamp format a20
SQL> select username,
timestamp
from dba_audit_session
where action_name = 'login'
and sysdate - timestamp > &site_specified_expiration_days;

Take the user returned from this report and expire the account.

SQL> alter user &username account lock;